【AWS Data Lake】ニアリアルタイムデータ分析環境・スピードレイヤを構築してみた(ハンズオン1)

【AWS Data Lake】ニアリアルタイムデータ分析環境・スピードレイヤを構築してみた(ハンズオン1)

Clock Icon2019.10.07

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは。DA事業本部の春田です。

管理のしやすさや拡張性の高さで注目を集めている、次世代のデータ分析基盤Data Lakeについて、ハンズオンにトライしてみました。

Datalake Handson

本記事では、Lab1~Lab3のニアリアルタイムデータ分析環境(スピードレイヤ)を構築していきます。

Lab1: はじめの準備

Lab1: はじめの準備

はじめにハンズオン共通で使用するVPC、EC2、IAM Roleを設定していきます。まずEC2で使用するキーペアを作成します。

上で作成したキーペア datalake-handson-haruta を用いて、CloudFormationからEC2インスタンスを作成します。

EC2の構築が完了したら、 datalake-handson-haruta の公開鍵でSSHログインし、 /root/es-demo/testapp.log にログが吐き出されているかを確認します。ログは2分おきに10件前後、10分おきに300件出力される仕様です。

ログが吐き出されていることが確認できたので、IAM Roleのアタッチに移ります。この場ではポリシーなしで作成します。

作成したIAM Roleを先程のEC2インスタンスにアタッチします。

最後に、EC2にFluentdをインストールして下準備完了です。

Lab2: アプリケーションログをリアルタイムで可視化

LLab2: アプリケーションログをリアルタイムで可視化

最初のLabでは、EC2で吐き出されているログをFluentdでElasticsearch Service(以降、ES)に送信し、Kibanaでログデータの可視化を行います。まずは、ESの起動を行います。

起動の際には、無料枠の t2.small.elasticsearch インスタンスを選択する点と、パブリックアクセスを許可する点に注意です。

ESの起動が完了したら、EC2にアタッチ済みのIAM Role handson-minilake に対して、 AmazonESFullAccess ポリシーをアタッチします。

ポリシーのアタッチが完了したら、EC2にログインし、FluentdからESにログデータを送信するための設定を行います。FluentdのESプラグインをインストールし、用意されているconfファイルを用いて張り替えていきます。

これで準備完了です。ES付属のKibanaに入り、ダッシュボードを作成していきます。Indexパターンを設定するほか、用意されているJSONファイルで可視化の画面を作成します。

ダッシュボードが完成しました。中身を確認してみます。

ログデータがいい感じに可視化されています。(※まもなくLab3に移ってしまったので、一時点のデータしか取れていません。)Lab1のアーキテクチャを現場で構築する場合は、Fluentdの設定とKibanaのダッシュボードの作成に手間がかかりそうですが、インフラの部分は簡単に構築できそうですね。

Lab3: アプリケーションログのリアルタイム可視化とアラーム

Lab3: アプリケーションログのリアルタイム可視化とアラーム

より使いやすくするために、EC2とESの間にCloudWatchをはさみ、アラーム機能を追加します。まずは、IAM RoleにEC2からCloudWatchにアクセスするための CloudWatchLogsFullAccess ポリシーを追加します。

EC2に入り、Fluentdを設定し直します。FluentdのCloudWatch Logsプラグインをインストールし、用意されているconfファイルで張り替えていきます。

ログにエラーが出続けてないか確認できたら、CloudWatch Logsの設定を行います。

先ほど設定したログは正常に出力されているようです。このログストリームをESに流せるように設定していきます。

ログを裏で流すのは自動で作成されるLambdaです。このLambdaがESに接続するために必要なIAM Roleを、この場で新規作成します。

ストリーミングが開始したら、Kibanaで先ほどと同じような設定を行い、ダッシュボードを作成します。

Discoverからindexに cwl-* を選択すれば、グラフが表示されます。

設定が完了しました。ダッシュボードも問題なく反映されています。

最後に、メトリクスがしきい値を超えたらメールを送信するような通知機能をCloudWatch Alarmsで作成します。ロググループ minilake_group からメトリクスフィルタを作成し、アラームを設定していきます。

通知を受信するSNSトピックはこの場で作成します。

設定が完了しました。アラーム状態になると、以下のようにメールが飛んできます。

このようにログストリームの間に一段CloudWatchをかませるだけで、ElastAlert等でESを監視せずとも、シンプルに通知機能を実装することができます。

最後に

今回は、AWS上でニアリアルタイムデータ分析環境を作成してみました。さすがはAWSと言ったところで、インフラの構築は簡単にできてしまいました。上記のような環境を実際に構築する場合には、FluentdとKibanaの知識があれば1日かからずともできてしまいそうですね!

長くなってしまったので、Lab4~Lab6は別記事に上げております。

【AWS Data Lake】長期間のデータをバッチ分析する環境・バッチレイヤを構築してみた(ハンズオン2)

興味ある方はぜひお試しください。

Datalake Handson

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.